home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Atari Mega Archive 1
/
Atari Mega Archive - Volume 1.iso
/
lists
/
gem
/
l_1199
/
947
< prev
next >
Wrap
Text File
|
1994-08-27
|
2KB
|
41 lines
Subject: Re: Gem List (fwd)
Date: Thu, 21 Jul 1994 10:51:39 -0400 (EDT)
From: Chris Herborth <herborth@53iss6.waterloo.ncr.com>
In-Reply-To: <2e2cfd5016cbf5@elfhaven.ersys.edmonton.ab.ca> from "Michel Forget" at Jul 19, 94 09:57:36 pm
Message-Id: <9407211058.aq23347@ncrhub1.NCR.COM>
Precedence: bulk
What you wrote:
> I'm not actually sure; I can only speak for myself, but I tend to respond
> when people say something I disagree with. That is why I keep posting
> these messages, though.
Me too! :-\
> >I'm
> >presuming that you're playing devil's advocacte a little here, since nobody
> >in their right mind would use the Malloc() GEMDOS call.
>
> Sigh. _I_ use it. (Yes, I feel stupid now, since now at least one reason
> why I should not.) Using malloc() is only a delay, though, for TOS 1.0
> users. If you allocate a lot of memory (like MasterBrowse does) then
> malloc() will end up calling Malloc() more that sixteen times, and you
> can say bye-bye to TOS 1.0. Is there -another- reason why I should not
> use it?
Most C libraries that have decent malloc() support (ie, to work around
that STUPID Malloc() bug) let you set the size of the smallest "chunk"
that actually gets allocated with Malloc(); I think GNU C's defaults to
64k, but you can change it by setting _blksize or something like that
(an extern long variable). You could set this based on the size of the
file (ie, set _blksize to 1/2 the file size or 1x the file size) and
then malloc() to your heart's content... only 1 (or maybe 2) call to
Malloc() will be generated, saving the poor TOS 1.0 user from mysterious
crashes...
--
----------========================_ /\ ============================----------
Chris Herborth \`o.0' herborth@53iss6.Waterloo.NCR.COM
Information Products Developer =(___)=
AT&T Global Information Solutions U